home *** CD-ROM | disk | FTP | other *** search
/ Cream of the Crop 20 / Cream of the Crop 20 (Terry Blount) (1996).iso / os2 / radius_2.zip / CRYPT.C < prev    next >
C/C++ Source or Header  |  1996-05-16  |  31KB  |  977 lines
  1. /*
  2.  * Copyright (c) 1989 The Regents of the University of California.
  3.  * All rights reserved.
  4.  *
  5.  * This code is derived from software contributed to Berkeley by
  6.  * Tom Truscott.
  7.  *
  8.  * Redistribution and use in source and binary forms, with or without
  9.  * modification, are permitted provided that the following conditions
  10.  * are met:
  11.  * 1. Redistributions of source code must retain the above copyright
  12.  *    notice, this list of conditions and the following disclaimer.
  13.  * 2. Redistributions in binary form must reproduce the above copyright
  14.  *    notice, this list of conditions and the following disclaimer in the
  15.  *    documentation and/or other materials provided with the distribution.
  16.  * 3. All advertising materials mentioning features or use of this software
  17.  *    must display the following acknowledgement:
  18.  *    This product includes software developed by the University of
  19.  *    California, Berkeley and its contributors.
  20.  * 4. Neither the name of the University nor the names of its contributors
  21.  *    may be used to endorse or promote products derived from this software
  22.  *    without specific prior written permission.
  23.  *
  24.  * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
  25.  * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
  26.  * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
  27.  * ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
  28.  * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
  29.  * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
  30.  * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
  31.  * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
  32.  * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
  33.  * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
  34.  * SUCH DAMAGE.
  35.  */
  36.  
  37. #if defined(LIBC_SCCS) && !defined(lint)
  38. static char sccsid[] = "@(#)crypt.c    5.11 (Berkeley) 6/25/91";
  39. #endif /* LIBC_SCCS and not lint */
  40.  
  41. #define    _PASSWORD_EFMT1        '_'    /* extended encryption format */
  42. #include <unistd.h>
  43. #include <limits.h>
  44. #include <pwd.h>
  45.  
  46. /*
  47.  * UNIX password, and DES, encryption.
  48.  * By Tom Truscott, trt@rti.rti.org,
  49.  * from algorithms by Robert W. Baldwin and James Gillogly.
  50.  *
  51.  * References:
  52.  * "Mathematical Cryptology for Computer Scientists and Mathematicians,"
  53.  * by Wayne Patterson, 1987, ISBN 0-8476-7438-X.
  54.  *
  55.  * "Password Security: A Case History," R. Morris and Ken Thompson,
  56.  * Communications of the ACM, vol. 22, pp. 594-597, Nov. 1979.
  57.  *
  58.  * "DES will be Totally Insecure within Ten Years," M.E. Hellman,
  59.  * IEEE Spectrum, vol. 16, pp. 32-39, July 1979.
  60.  */
  61.  
  62. /* =====  Configuration ==================== */
  63.  
  64. /*
  65.  * define "MUST_ALIGN" if your compiler cannot load/store
  66.  * long integers at arbitrary (e.g. odd) memory locations.
  67.  * (Either that or never pass unaligned addresses to des_cipher!)
  68.  */
  69. #if !defined(vax)
  70. #define    MUST_ALIGN
  71. #endif
  72.  
  73. #ifdef CHAR_BITS
  74. #if CHAR_BITS != 8
  75.     #error C_block structure assumes 8 bit characters
  76. #endif
  77. #endif
  78.  
  79. /*
  80.  * define "LONG_IS_32_BITS" only if sizeof(long)==4.
  81.  * This avoids use of bit fields (your compiler may be sloppy with them).
  82.  */
  83. #if !defined(cray)
  84. #define    LONG_IS_32_BITS
  85. #endif
  86.  
  87. /*
  88.  * define "B64" to be the declaration for a 64 bit integer.
  89.  * XXX this feature is currently unused, see "endian" comment below.
  90.  */
  91. #if defined(cray)
  92. #define    B64    long
  93. #endif
  94. #if defined(convex)
  95. #define    B64    long long
  96. #endif
  97.  
  98. /*
  99.  * define "LARGEDATA" to get faster permutations, by using about 72 kilobytes
  100.  * of lookup tables.  This speeds up des_setkey() and des_cipher(), but has
  101.  * little effect on crypt().
  102.  */
  103. #if defined(notdef)
  104. #define    LARGEDATA
  105. #endif
  106.  
  107. /* compile with "-DSTATIC=int" when profiling */
  108. #ifndef STATIC
  109. #define    STATIC    static
  110. #endif
  111. STATIC void init_des();
  112. STATIC void  init_perm();
  113. STATIC void  permute();
  114. int des_setkey(register const char *key);
  115. int des_cipher(const char *in,    char *out,    long salt,    int num_iter);
  116.  
  117. #ifdef DEBUG
  118. STATIC prtab();
  119. #endif
  120.  
  121. /* ==================================== */
  122.  
  123. /*
  124.  * Cipher-block representation (Bob Baldwin):
  125.  *
  126.  * DES operates on groups of 64 bits, numbered 1..64 (sigh).  One
  127.  * representation is to store one bit per byte in an array of bytes.  Bit N of
  128.  * the NBS spec is stored as the LSB of the Nth byte (index N-1) in the array.
  129.  * Another representation stores the 64 bits in 8 bytes, with bits 1..8 in the
  130.  * first byte, 9..16 in the second, and so on.  The DES spec apparently has
  131.  * bit 1 in the MSB of the first byte, but that is particularly noxious so we
  132.  * bit-reverse each byte so that bit 1 is the LSB of the first byte, bit 8 is
  133.  * the MSB of the first byte.  Specifically, the 64-bit input data and key are
  134.  * converted to LSB format, and the output 64-bit block is converted back into
  135.  * MSB format.
  136.  *
  137.  * DES operates internally on groups of 32 bits which are expanded to 48 bits
  138.  * by permutation E and shrunk back to 32 bits by the S boxes.  To speed up
  139.  * the computation, the expansion is applied only once, the expanded
  140.  * representation is maintained during the encryption, and a compression
  141.  * permutation is applied only at the end.  To speed up the S-box lookups,
  142.  * the 48 bits are maintained as eight 6 bit groups, one per byte, which
  143.  * directly feed the eight S-boxes.  Within each byte, the 6 bits are the
  144.  * most significant ones.  The low two bits of each byte are zero.  (Thus,
  145.  * bit 1 of the 48 bit E expansion is stored as the "4"-valued bit of the
  146.  * first byte in the eight byte representation, bit 2 of the 48 bit value is
  147.  * the "8"-valued bit, and so on.)  In fact, a combined "SPE"-box lookup is
  148.  * used, in which the output is the 64 bit result of an S-box lookup which
  149.  * has been permuted by P and expanded by E, and is ready for use in the next
  150.  * iteration.  Two 32-bit wide tables, SPE[0] and SPE[1], are used for this
  151.  * lookup.  Since each byte in the 48 bit path is a multiple of four, indexed
  152.  * lookup of SPE[0] and SPE[1] is simple and fast.  The key schedule and
  153.  * "salt" are also converted to this 8*(6+2) format.  The SPE table size is
  154.  * 8*64*8 = 4K bytes.
  155.  *
  156.  * To speed up bit-parallel operations (such as XOR), the 8 byte
  157.  * representation is "union"ed with 32 bit values "i0" and "i1", and, on
  158.  * machines which support it, a 64 bit value "b64".  This data structure,
  159.  * "C_block", has two problems.  First, alignment restrictions must be
  160.  * honored.  Second, the byte-order (e.g. little-endian or big-endian) of
  161.  * the architecture becomes visible.
  162.  *
  163.  * The byte-order problem is unfortunate, since on the one hand it is good
  164.  * to have a machine-independent C_block representation (bits 1..8 in the
  165.  * first byte, etc.), and on the other hand it is good for the LSB of the
  166.  * first byte to be the LSB of i0.  We cannot have both these things, so we
  167.  * currently use the "little-endian" representation and avoid any multi-byte
  168.  * operations that depend on byte order.  This largely precludes use of the
  169.  * 64-bit datatype since the relative order of i0 and i1 are unknown.  It
  170.  * also inhibits grouping the SPE table to look up 12 bits at a time.  (The
  171.  * 12 bits can be stored in a 16-bit field with 3 low-order zeroes and 1
  172.  * high-order zero, providing fast indexing into a 64-bit wide SPE.)  On the
  173.  * other hand, 64-bit datatypes are currently rare, and a 12-bit SPE lookup
  174.  * requires a 128 kilobyte table, so perhaps this is not a big loss.
  175.  *
  176.  * Permutation representation (Jim Gillogly):
  177.  *
  178.  * A transformation is defined by its effect on each of the 8 bytes of the
  179.  * 64-bit input.  For each byte we give a 64-bit output that has the bits in
  180.  * the input distributed appropriately.  The transformation is then the OR
  181.  * of the 8 sets of 64-bits.  This uses 8*256*8 = 16K bytes of storage for
  182.  * each transformation.  Unless LARGEDATA is defined, however, a more compact
  183.  * table is used which looks up 16 4-bit "chunks" rather than 8 8-bit chunks.
  184.  * The smaller table uses 16*16*8 = 2K by